Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make coredata and environment fully type safe #13737

Draft
wants to merge 20 commits into
base: master
Choose a base branch
from

Conversation

dcbaker
Copy link
Member

@dcbaker dcbaker commented Oct 1, 2024

I give you a mypy compliant environment and coredata. There isn't actually that much here once we get the options module safe. With this in place the next big roadblock to full type safety is the build module.

This is built on #13620, and thus this is a draft

This provides a method to get choices for options in a printable form.
The goal is to make refactoring options simpler.
This saves a *tiny* bit of typing, but at the cost of requiring either
the current solution of throwing up our hands and saying "typing is too
hard, better to have bugs!" or an extensive amount of `TypedDict`s,
`overloads`, and a very new version of mypy. Let's get our type safety
back, even if it means writing a little bit more code.
This reduces code, makes this clearer, and will be a nice step toward
the goal of getting everything typesafe
This will allow us to take choices out of the UserOption class, which
doesn't actually use this attribute.
Which wants a string, but then passes that string to a function that
wants an OptionKey, which means that we'll always miss the lookup in
BULITIN_DIR_NOPREFIX_OPTIONS, and return the default. The only case this
gets used we cast an OptionKey to str, and then pass that. So instead,
do the cast inside the function when necessary and pass the OptionKey
They are very similar, but they are not exactly the same. By splitting
them we can get full type safety, and run mypy over the options.py file!
This allows us to hide type differences inside the options module, but
still get accurate change information.
…on types

The fact that UserOption is generic is really an implementation detail,
not something to be used publicly. So by having an `AnyOptionType`
alias, we can get better type checking, as can be seen by the patch as a
whole. One of the big fixes it replace open-coded equivlalents of
`MutableKeydOptionDictType` with that type alias.
@dcbaker dcbaker force-pushed the submit/type-safe-coredata branch 2 times, most recently from 1300e3a to e350d38 Compare October 1, 2024 19:59
It's not re-exported from options, so it should come from coredata
This allows us to get rid of more Any use, so there's a lot of typing
fallout.
These include things like not narrowing unions and boolean error
handling
We don't actually allow anything except elementry types (`str`, `bool`,
`int`, `array[str]`) here, so we can tighten the typing. This in turn
helps us to simplify the typing in environment.py
This as much as anything is to stop lying to envconfig about the
potential types it will be given.
There were two issues, one was that we were calling from an interpreter
method to an interpreter method, and second that we needed to narrow
some option values.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant